USB environments are ubiquitous in modern electronics devices (e.g., servers, personal computers (“PCs”), tablet PCs, cell phones, automobile infotainment systems, personal gaming systems, toys, etc.). It is a “universal” interface that allows keyboards, monitors, printers, storage devices, cameras, phones, toys, games, and numerous other electronic devices to work on a single interface. With USB devices, particularly devices like card readers and similar, it is valuable to have a side channel into the device, using, for example, a separate interface, such as e.g. SPI, I2C, UART, etc., from which the downstream USB resource, for example a media card in the case of a card reader, etc., can be accessed directly. One approach is to require that such access be done through the upstream USB port, but this may complicate the logic and/or compromise system performance.
For example, in a USB device (such as a dual card reader) that does not support USB streams, only one USB packet can be processed at a given time, and any further packets are held off until processing of the current packet is completed. This means that if a side channel transfer comes into the system through the upstream USB port, then all USB packets must be held off, even if the physical resource (e.g., a memory card) is not being accessed.
In a USB device that supports USB streams, the USB device controller will process N number of streams that come in sequentially. With USB streams, a new packet can be accepted into the device before the previous packet has been processed, up to the storage and processing capability of the device. This can be accomplished by having a central command arbiter that examines each USB packet and determines to which physical resource (e.g., memory card #1, memory card #2, CPU, etc.) that packet should be routed. By routing only to the physical resource that the packet is intended for, the logic in the physical resource can be simplified.
However, even with devices that support USB streams, a side channel access to one of the physical resources on the device will need to be processed by the CPU in order to determine the correct steering. On devices that do not support out-of-ordering processing of packets (which is most devices, as it is simpler not to support it), processing of all other packets must be held off until the side channel packet is correctly steered, so that the order of all packets is maintained. This requires communication and synchronization between the side channel logic and the USB device controller, which may be complicated to implement correctly.
Further, requiring the side channel access through the upstream USB port may not be acceptable to some users that either have to use (or want to use) a separate interface, such as SPI, I2C, UART, etc. to access the USB device. Allowing side channel access to the USB device via one of these separate interfaces can complicate the hardware and associated software routines. For example, implementing the functionality to multiplex read and write commands/data on such a side channel with the read and write commands on the USB upstream can be complicated to implement and often would result in a proprietary command and addressing scheme and/or additional hardware requirements (e.g., an additional arbiter layer that determines access priority as between commands originating from the USB host and commands originating via the separate SPI/I2C/UART/etc. interface).